Commonly, software systems require the storage or transmission of discrete units of data in a chronologically ordered fashion. For efficiency purposes, it is preferable to store or transmit data in large blocks. This eliminates the need for many small disk accesses or transmissions of small network packets, which generally have an adverse effect on system performance. It is also common for a software system that chronologically stores units of data in memory to allow direct memory access to collected, discrete units of data.
Software systems having multiple processes and/or multithreaded processes usually use a single shared memory buffer for these discrete units of data. At various times, a process or thread (referred to as a “writer” herein) may reserve a region of memory in the buffer to record its data. From time to time, the data collection operation may be reset and the data currently stored in the buffer should be cleared.
Since the buffer resides in a shared region of memory, the software system should employ a reservation system that ensures concurrent operations do not produce unexpected results. The reservation system should synchronize reservation requests from writers to prevent overlapping. Synchronization is also employed when writing out the data stored using the reservations to a disk or other non-volatile medium or transmitting such data across a network and when clearing the data from reserved memory.
One application of the reservation system for storing data to a shared memory buffer is a diagnostic facility. Mission critical software products employ diagnostic facilities to collect discrete information about the state of the application allowing the application to be serviced from the field. The efficiency of collecting diagnostic information is crucial specifically in a large, complex system having numerous applications, each having one or more writers executing concurrently. The diagnostic facility is usually shared across the entire system so it can provide an overall impression of the system's state. Ideally, the diagnostic facility should have zero impact on the system's performance and functionality. The facility simply needs to quickly record discrete amounts of diagnostic data in the facility's shared memory buffer. Unfortunately, the synchronization of the shared memory introduces performance penalties. In a worst case scenario, the entire system becomes serialized because of lack of performance crucial to the synchronization mechanism. This could lead to a situation where a problem in the system could not be properly diagnosed because of the negative performance impact of the diagnostic facility.
A diagnostic facility reservation system typically comprises collection and parsing stages. The collection stage occurs when writers make reservations of a portion of the shared memory and store data in those reserved portions. In this stage, the data in the shared memory buffer may be written to disk or may be cleared if the buffer is reset. Performance is critical in this stage because the reservation system should attempt to minimize its impact on the application.
The parsing stage involves examining the collected data obtained during the collection stage; the collected data is typically stored in a data file. Performance is relatively unimportant in this stage. Examining the data file is often independent of the application's core function. It may even be performed on a different computer. Reservation systems that simplify the parsing stage typically penalize the performance of the collection stage.
Existing reservation system implementations employ overly complicated synchronization mechanisms, using semaphores, mutexes, etc.
Other software reservation systems usually synchronize for the entire duration of the operation. For example, the reservation logic is usually implemented using the following steps: 1) Wait until the shared memory buffer is unlocked; 2) Lock the shared memory buffer (synchronize); 3) Make the reservation; 4) Return the reservation region to the writer; 5) Wait until writer is finished using the reserved region; and 6) Unlock the shared memory buffer. Clearing or storing the buffer to disk follows a similar logic, comprising steps of: 1) Waiting until the shared memory buffer is unlocked; 2) Locking the shared memory buffer (synchronize); 3) Clearing the shared memory buffer (or writing to disk); and 4) Unlocking the shared memory buffer.
This lengthy lock-out approach causes writers to queue up, waiting for their chance to acquire the shared memory lock. The operations that occur “under the lock” take a relatively long time, especially the file input/output (I/O) involved in storing the buffer on disk. This may cause the reservation system to serialize the entire software system.
Therefore, there is a need for a reservation system to provide efficient memory reservation in a shared memory buffer. Furthermore, the needed reservation system should minimally impact the entire software system while memory reservation is being undertaken. The need for such a system has heretofore remained unsatisfied.